home *** CD-ROM | disk | FTP | other *** search
/ Super PC 34 / Super PC 34 (Shareware).iso / spc / UTIL / DJGPP2 / V2 / DJTST200.ZIP / tests / libc / ansi / math / elefunt / readme < prev    next >
Encoding:
Text File  |  1987-06-17  |  3.0 KB  |  65 lines
  1.                C Version of the Code & Waite
  2.           ELEFUNT Elementary Function Test Package
  3.                         [15-Jun-87]
  4.  
  5. This C version of the ELEFUNT test package was translated by
  6. Ken Stoner (GU.STONER@SCIENCE.UTAH.EDU) and Nelson H.F.
  7. Beebe (BEEBE@SCIENCE.UTAH.EDU) at the Center for Scientific
  8. Computing, Department of Mathematics, University of Utah.
  9. The translation was carried out by converting the original
  10. FORTRAN code to Ratfor automatically with the Unix struct
  11. utility, then hand editing the Ratfor to C, which resemble
  12. one another.
  13.  
  14. Considerable care has been taken to match the output format
  15. of the two versions, so that after the characters
  16. +-0123456789 have been converted to blanks, the output
  17. listings should substantially agree.  One error was
  18. corrected in FORMAT 1030 in TPOWER--a missing right
  19. parenthesis.  The FORTRAN version has some inconsistencies
  20. in the number of blank lines used for spacing the output; we
  21. have opted in favor of uniformity in the C version.
  22.  
  23. C is problematic for numerical work on several grounds:
  24.         * Parentheses in expressions cannot be used to
  25.           enforce evaluation order; temporary variables must
  26.           be introduced.  This was particularly a problem in
  27.           machar.c.
  28.         * C has float and double data types, but an
  29.           implementation is free to implement these
  30.           in the same precision (PCC-20 uses only single
  31.           precision); the run-time library is written only
  32.           in type double.
  33.         * The behavior of library functions with respect to
  34.           out-of-range arguments, or arguments which would
  35.           result in substantial accuracy loss, is not
  36.           standardized.  Most C run-time libraries simply
  37.           set the global error value "errno" to a non-zero
  38.           value and return an arbitrary function result.
  39.           Code to test errno has been added to the test
  40.           programs.
  41.         * The behavior of floating-point arithmetic in
  42.           response to  underflow or overflow is not
  43.           well-defined.
  44.  
  45. In addition, machines with IEEE arithmetic (which is
  46. provided by most newer architectures) place additional
  47. demands on numerical software because they have
  48. computational units of greater precision than is stored in
  49. memory.  For example, several implementations compute with
  50. 80-bit extended precision, but store 32-bit or 64-bit values
  51. in memory.  Code in machar is particularly sensitive to
  52. this, and it has been necessary to force memory stores in
  53. intermediate expressions by calling a function
  54. store(&memval).  Since the address of a memory location is
  55. passed to store(), that location can potentially be
  56. modified, and the caller of store() must then reload the
  57. memory value upon return, rather than using a value that
  58. might exist in a higher-precision register.
  59.  
  60. The C version has been written using type "float"; the
  61. Makefile's for it provide an implicit "#define float double"
  62. for those systems in which the two precisions are
  63. implemented differently, so that the tests are carried out
  64. at the precision of the run-time library.
  65.